System and method for managing purchasing contracts

ABSTRACT

A system and method of managing purchasing contracts between supplier entities and customer entities for the purchase of products includes the step of generating at least one purchasing contract between at least one supplier entity (e.g., a product originator such as an airline company or a distributor such as travel agency) and at least one customer entity. The purchasing contract generated is one that is applicable to one or more contracted purchasing transactions effected, at least partially, through a computerized system. The generating step includes identifying one or more contract terms, wherein each contract term has one or more term attributes, and storing a term data set of the term attributes associated with each contract term in one or more computer databases. The method also involves collecting transaction data relating to one or more purchasing transactions and storing the transaction data in one or more computer databases. Preferably, a computer program is executed to identify one or more of the purchasing transactions as a contracted transaction (i.e., applicable to a specific contract) by selecting at least a portion of the transaction data for a purchasing transaction and comparing the selected portion with the term attributes for a contract term. In this way, the transaction may be identified as a contracted transaction if the selected portion is identified with one or more of the term attributes.

BACKGROUND OF THE INVENTION

The present application claims the benefit of the filing date of U.S.Provisional Application Ser. No. 60/194,538, filed Apr. 3, 2000, (whichis hereby incorporated by reference for all purposes).

The present invention relates generally to a system and method formanaging information or data and, alternatively, such a system andmethod for generating, monitoring, managing and/or otherwise maintainingcertain aspects of a contract relationship. The present invention isparticularly adapted to a system and method for generating, managingand/or monitoring a purchasing contract relationship such as a bulkpurchasing contract between a common carrier entity such an airlineoperator and a customer entity. Further, the inventive system and methodare particularly adapted for implementation via or on an electronicenvironment such as any client-server system including thoseincorporating terminals, personal computers, digital personal assistantsand the like, the Internet, or an Intranet.

Businesses reward customer volume buying with discounts or deals.Contracted deals comprise one or more purchasing requirements, or terms,for volume buying. Contract terms may include commitments for thepurchase of a specified number of units, or the expenditure of amonetary amount, or that a designated share of a company's purchasing bededicated to a specified supplier. Each party seeks financial gain fromthe deal. The supplier seeks to increase volume and to generate higherunit sales and profits. The customer seeks to lower costs throughdiscounts.

In a global business setting, suppliers often form alliances to provideservices to customers worldwide. Alliance deals involve contract termsfrom two or more suppliers. Both suppliers and customers benefit fromalliance deals. A supplier can extend its services into markets which itwould not ordinarily serve but which may be served by an alliancepartner. Customers, on the other hand, are able to consolidate theirglobal purchasing volume to benefit from worldwide discounts with areduced number of suppliers.

Many of such contractual relationships necessarily require management ofcertain aspects of contracts in an electronic or computerizedenvironment. Although the utilization of electronic or computer networksfacilitate the various contract management processes, it can presentcertain challenges as well. For example, more than one distributor willprobably be authorized to sell products to a customer. Accordingly, asupplier will collect contract-related information from more than onesource and will often receive the information in raw or non-standardizedform. In addition, suppliers and distributors are often located indifferent parts of the world and may use different systems which produceincompatible electronic transactions.

SUMMARY OF THE INVENTION

It is, therefore, one of several objects of the present invention toprovide a system and method for maintaining a contract including thetasks of generating, managing, and monitoring certain aspects of thecontract (sometimes collectively referred to herein as “contractmanagement”). More particularly, it is an object of the invention toprovide such a system or method for managing a contract between one ormore supplier entities and one or more customer entities. In thisregard, a preferred system or method is one that is particularly adaptedto a computerized or electronic environment and which allows for thecollection, manipulation or management of information in a manner thatfacilitates the various contract management tasks. Various aspects ofthe system or method may be employed by the supplier entity (including adistributor), a customer entity or a third-party agent or facilitator.

In one aspect of the invention, there is provided a system and method ofmanaging purchasing contracts between supplier entities and customerentities for the purchase of products. The method includes the step ofgenerating at least one purchasing contract between at least onesupplier entity (e.g., a product originator such as an airline companyor a distributor such as a travel agency) and at least one customerentity. The purchasing contract generated would be one that governs, oris applicable to, one or more contracted purchasing transactionseffected, at least partially, through a computerized system (e.g., thepurchase of a ticket from an origination city to a destination city).The generating step includes identifying one or more contract terms,wherein each contract term has one or more term attributes, and storinga term data set of the term attributes associated with each contractterm in one or more computer databases. For example, contract termattributes stored as term data set in an airline industry applicationdescribed herein include contract and term unique identifier. The methodalso involves collecting transaction data relating to one or morepurchasing transactions and storing the transaction data in one or morecomputer databases. For example, transaction data collected in anairline industry application described herein include origin anddestination, supplier and customer information.

Preferably, a computer program is executed to identify one or more ofthe purchasing transactions as a contracted transaction (i.e.,applicable to a specific contract) by selecting at least a portion ofthe transaction data received for a purchasing transaction and comparingthe selected portion with the term attributes for a contract term. Inthis way, the transaction may be identified (i.e., marked) as acontracted transaction if the selected portion is identified with one ormore of the term attributes. For example, in an application for theairlines industry, ticketing transactions are identified to a contractby examining the departure date, the customer identity, or ticketcompany or agency, among other attributes.

The method further includes the step of generating a collection ofcontract transaction data sets by associating at least a portion of thetransaction data of each identified contracted transaction with at leasta portion of each term data set with which the transaction isidentified. For example, a unique contract term identifier or ID, aunique contract identifier or ID, and/or term requirement or discountdesignation may be associated with each identified transaction data set.Such a contract-specific and preferably computer-accessible collectionof data sets may be utilized to measure contract term performance andalso to generate reports and summaries for the contract.

The inventive system and method allow a supplier to manage a contractwhereby the customer may transact with a plurality of distributorsand/or the supplier. It should be noted that from hereon the term“supplier” or “supplier entity” may refer to a product originator (e.g.,an airline) as well as a distributor (e.g., a travel agency). Thepresent invention also facilitates the management of contracts whereinthe product generator and distributors are located in different parts ofthe world and/or use systems which produce incompatible electronictransactions or transaction data. In this respect, one aspect of theinvention is the creation of a standardized data format and also acontract-specific computer accessible data set for a contract orcontract term.

The present inventive system and method also provide a means for asupplier entity to identify transactions to a contract or a contractterm. Further, such a means is provided that is implemented throughcomputerized systems and computer programs operable therewith. In thisway, an automated method of contract management is provided.

In a system and method for measuring contract performance, i.e., forbulk purchases over a period of time, the present invention provides asystem and method, which converts information or data, received forcontracted transactions into a common or standardized format. The commonformat facilitates identification of transaction data sets applicable toa contract term, and generation of contract-specific transaction datasets from which performance of a contract term may be measured and fromwhich performance reports may be generated. Accordingly, suppliers aremore consistent and more accurate in their payment of discounts tocustomers. Also, the profitability of an account can be measured andtracked by all forms of revenue and taking into account the discountpayments. Further, compensation and incentive programs based on amountsand/or totals of contracted transactions may be structured for internalsales personnel.

In yet another aspect of the invention, a method of generating apurchase contract is provided. The method is particularly adapted foruse with a method of managing purchasing contracts between at least onesupplier entity and at least one customer entity, wherein the purchasingcontract is applicable to one or more contracted purchasing transactionsfor products effected, at least partially, through a computerizedsystem. The method of generating the contract includes the initial stepsof collecting transaction data relating to historical purchasingtransactions by the customer entity and/or satisfying a particularmarket profile, and storing, in one or more databases, a set oftransaction data for each historical purchasing transaction. The methodalso includes the steps of defining one or more proposed contract termsand defining one or more term attributes associated with each proposedcontract term and storing the term attributes as a term data set in oneor more databases. Then, the method requires the step of executing acomputer program to qualify each proposed contract term. This qualifyingstep includes selecting one or more of the stored term attributes (e.g.,total units requirement, or percent/share of total units or value), andidentifying each transaction data set that satisfies the selected termattributes.

The inventive method further includes forecasting a performance resultof the proposed contract term using, as input, at least a portion ofeach transaction data set identified and qualifying the proposedcontract term if the forecasted result satisfies a predeterminedperformance criteria in the form of one or more term performance rules.For example, three rules may apply. A first rule may require a specifiedshare of a company's purchasing be made from the supplier while a secondrule may require a specified monetary amount be made from the supplier.A third rule may require a specified unit amount of purchases be madefrom the supplier. Before a term is deemed acceptable, or thusqualified, it must satisfy one or more, or a combination of f theserules. Once terms are qualified, a purchasing contract incorporating oneor more of the qualified terms is assigned between the supplier entityand the customer entity.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified system configuration diagram for the inventivesystem;

FIGS. 2A-2C are simplified flow charts illustrating a method ofgenerating a contract according to the invention;

FIG. 3 is a simplified illustration of a plurality of databases whichare generated and/or utilized according to the present invention;

FIGS. 4A-4B are simplified block diagrams illustrating the generation ofa data format for a contract-designated transaction, according to theinvention;

FIGS. 5A-5B is a simplified flow chart illustrating the creation ofentity and contact databases, according to the invention;

FIG. 6 is a simplified flow chart illustrating the creation of a termrules database, according to the invention;

FIG. 7A-7C are simplified flow charts illustrating a data normalizationprocess, according to the invention;

FIG. 8A-8I are simplified flow charts illustrating a process of defininga contract and contract terms therefor, according to the invention;

FIGS. 9A-9C are simplified flow charts illustrating a process of markingdetailed transactions, according to the invention;

FIGS. 10A-10B are simplified flow charts illustrating a process ofcreating a transaction summary database, according to the invention;

FIGS. 11A-11B illustrates a process of forecasting term performance,according to the invention;

FIGS. 12A-12B illustrates a process of forecasting contract performance,according to the invention;

FIGS. 13 is a simplified flow chart illustrating a method of producingand distributing contract performance information, according to theinvention;

FIGS. 14A-14B is a simplified flow chart illustrating a process ofauditing discounted transactions, according to the invention;

FIG. 15 is a simplified flow chart illustrating a process of themeasurement of actual contract performance, according to the invention;

FIG. 16 is a flow chart illustrating a process of final reconciliationof contract terms, according to the invention;

FIG. 17 is a simplified flow chart illustrating a process for the payoutof the discount, according to the invention;

FIG. 18 is a simplified flow chart illustrating a process of themeasurement sales goals, according to the invention;

FIG. 19 is an illustration of the exemplary use of detailed transactiondata used for the purpose of contracting, according to the invention;

FIG. 20 is an illustration of an exemplary Market Analysis Summary tableaccording to the invention, according to the invention;

FIGS. 21A, 21C are illustrations of a Term Definition Module, accordingto the invention;

FIG. 22 is an illustration of the financial forecast for terms and acontract; according to the invention; and

FIG. 23 is an illustration of a report monitoring actual performance ofa contract, according to the invention.

DETAIL DESCRIPTION OF THE DRAWINGS DEFINITIONS

To facilitate description of the embodiment of the invention illustratedin the drawings, brief explanations of certain operative terms andconcepts follow. These explanations should not, however, operate tolimit the scope of the invention.

As used heretofore, a “contract” establishes a legal relationshipbetween a supplier entity (e.g., a supplier, distributor, originator, oralliance partner) and a customer entity. A contract is characterized bycontract attributes including one or more contract “terms.” A “term”defines an obligation on the part of one of the parties conditioned uponthe satisfaction of term performance criteria. The term is, itself,defined by “term attributes.”

The object of a contract between a supplier entity and customer entityare one or more “contract transactions” or “contracted transactions.”These are transactions which effect the purchase of a supplier entity'sproduct by the customer and which are governed by or apply to thecontract. Records of these contract transactions include informationrelated to the contract including a unique customer identifier, a uniquecontract identifier and contract term identifier. Identification of aspecific contract transaction requires that information about thetransactions be individualized. Sometimes, a record of a contracttransaction will actually contain more than one contract transaction (asdefined by the contract), i.e., a parent transaction. This informationneeds to be individualized to obtain each of the individual contracttransactions. Conversely, a record may contain information that does notadequately identify the transaction as a contract transaction, i.e., apartial transaction. Similar to the parent transaction, this transactionmust be individualized to obtain the individual contract transaction.

A “data set” is a collection of related information or data. A data setmay reside on electronic storage media in a database or the data set mayreside in the memory of the computer. A data set may comprise datastored in a plurality of databases but which are somehow associated forelectronic access purposes. As shown herein, the data set may bedisplayed as rows in a database table.

A “definition” as used herein (e.g., “market definition”, “termdefinition”, “contract definition”) may refer to the criteria thatdescribes these items that are stored in a database in a computerlanguage format, such as Structured Query Language.

A “data format” may refer to the unique collection, representation andarrangement of data in a data set. Typically, the data representsattributes. Although attributes are usually found within a row of a dataset arranged in a particular order, the attributes may be arranged inany manner so long as the particular attribute type and value can beidentified.

A “database table” as used herein refers to a means of storing structuredata in an electronic media accessed by computerized processes.

An “identifier” is a data value or a combination of values that uniquelyreference a particular entity or subject such as a Supplier, Customer,Contract, Contract Term, etc. The identifier may be any combination ofcharacters, numbers, or any other representation so long as the valueestablishes the entity.

A “software module” or “module” as used herein means a component of thesystem that carries out instructions, rules, and processes of theinventive application.

“Structured Query Language” (SQL) is one form of computer language usedto store structured commands to a database.

A “term rule” is an attribute that defines a performance requirement orcriteria which must be satisfied before a contract term is deemedsatisfied or fulfilled. In generating a contract, a proposed contractterm may be required to satisfy, e.g., based on historical data, aspecific term rule. For example, a term rule may be set up thatspecifies a numerical amount of product units purchased, a totalpurchase value or monetary amount, a percentage or share of purchasedunits or total purchase value. In other words, before a contract iscreated or qualified, each contract term may have to meet the specificrequirements of the term rule. These term rules can later be used as aperformance or term parameter to gauge the performance of the particularcontract.

The following terms are used to describe the system and inventivemethod's application in the travel industry.

A “Directional Pair” describes the originating and destination airportsbut counts the originating airport twice. For example, a round tripbetween San Francisco (originating) and Chicago is indicated by the codeSFO-ORD and recorded twice (as 2 flights).

“Front-end Terms” are contract terms which provide for a discount to thecustomer discount at the point of sale.

“Back-end Terms” are terms which, if satisfied, provide payment of thediscount to the customer at the end of a contract period.

“Host” or “Host Carrier” is the contracting airline operating thesystem.

A “Market” as used herein, refers to the passengers trueorigin-destination on the same, or alliance carrier, which may becomprised of multiple segments (i.e. ABQ-HOU-AMS).

The “Market Share Database” is a summary database containing valuesestablishing the minimum share the carrier requires for any market (tomeet a contract term).

An “OD Pair” is an origin and destination pair describes the originatingand destination airports in alphabetical order of the originatingairport. ODPairs are used to count the total number of flights betweentwo airports. For example, a round trip flight between San Francisco andChicago is indicated by the code ORD-SFO and recorded twice (as 2flights).

Exemplary Application In a Common Carrier Industry

The present invention is particularly adapted for implementation in theoperating environment of the airline industry or other common carrierindustry. Airlines enter into contracts with companies for the volumepurchase of airline seats at discounted prices for business travelers.The terms of these contracts may require commitments for the purchase ofa specified number of seats, or the expenditure of a monetary amount, ora designated share of a customer company's purchase (count or monetaryamount) to be dedicated to the airline. Accordingly, these contracts canrepresent large financial commitments by customers and involvesignificant ticket price discounts.

Airlines typically measure contract term performance by examiningreports or data provided by the customer; or require a travel agency tomanually input a term code in a travelers' data record; or rely uponinternal data that are exclusive to the airline, such as revenueaccounting data. The product data acquired are often raw and not inreadily usable form for some contract management tasks. Typically, theinformation initially collected are in flight segment data form whichdoes not properly reflect the traveler's ultimate destination. Amongother things, the form of this data and the means by which the data arecollected do not readily allow for a transaction to be matched oridentified with a contract term (so that measurement of the contractterm's performance reflect the occurrence of these transactions).

Moreover, without agent intervention, the record of these transactionsdo not automatically or readily indicate information relevant to acontract term such as the count of seats, amount of expenditure, theairline's share of business, and other transaction information orvalues. Contracted terms and fares are inconsistently displayed in thevarious airline booking databases. Agents typically enter special codesto designate fares and thus, since this is a manual operation, theinformation entered is often incomplete or inaccurate. Additionally,agents enter codes which apply to only one specified carrier, and whichcannot be associated to other carriers. As a result, the measure of termperformance may be inadequate since the total number of passengers,total expenditure, and share of flights for a given company may not takeinto account flights on other airlines. Thus, the inventive system andmethod provide for the collection, identification, and/or generation oftransaction information or data which facilitate the measurement ofcontract performance for all carriers.

Airlines are also extending their reach to new markets by formingairline alliances comprised of two or more carriers. An airline withinan alliance may “code-share” which is the practice of using the flightnumber or code of the alliance partner in addition to its own flightnumber or code. While a traveler's itinerary may show one airline to adestination, more than one airline may actually be flown. In amultinational setting, contracts often apply to code-share flights.Therefore, in one aspect of the invention, the inventive system andmethod are adapted to identifying transactions involving code-shareflights with a contract term and/or converting transaction data relatingto such flights into a form that is suitable for the management of acontract (including measurement of a contract term).

Airlines distribute their products (airline seats) through electronicsystems such as Global Distribution Systems, travel agencies, orInternet booking portals. Tickets may be purchased through any one ofthousands of travel agent ticketing locations located around the world.While ticket data may be collected in airline revenue accounting systemsor in travel agent accounting systems, many of such systems create anduse incompatible data formats. Thus, an airline examining data madeavailable to it may not be able to recognize that a traveler isqualified for a corporate discount. Moreover, when airlines do recognizesuch a traveler or transaction, identifying tickets which qualify fordiscounts is done by entering a unique number into a computer system.Again, since this step is performed manually, it is subject to error.The present invention provides a system and method for identifyingticketing transactions applicable to a contract between airline and acustomer company, collecting transaction data therefor, and storingand/or converting all of the transaction data in a common format. Thestored/converted data may be referred to as transaction data sets andmay be further manipulated or marked so as to be identifiable with acontract and/or contact term, or used for evaluating or qualifyingproposed contracts or contract terms.

Accordingly, FIGS. 1-23 and the detail description of these Figuresrelate to an application of the inventive system and method to acontractual relationship between a supplier entity such as an airlinecompany or its distributor, and a customer entity such as a largenational corporation. The products which are the subject of thecontractual relationship are seats or flights. These seats areidentifiable by carrier, seat number, cabin class and flight segment(i.e., origin-destination or OD). The application of the inventivesystem and method to other types of contractual relationships willbecome apparent to one skilled in the art upon reading the descriptionand/or claims and/or viewing the drawings, all provided herein.

Overview of Figures

FIGS. 1-23 depict systems and processes embodying various aspects of theinvention. More particularly, FIGS. 1-23 illustrate one or moreinventive systems and methods particularly adapted for use with or inregard to a purchasing contract between a supplier entity such as acommon carrier (e.g., an airline company) or a distributor (e.g., atravel agency) associated with the common carrier, and a customer entitysuch as a large corporation.

Among other functions, the systems and processes illustrated in theFigures and described herein provide for the following functions: (1)identify and record information on business entities and contacts; (2)define performance term rules indicating the minimum and maximumfinancial performance requirements for the term and the contract; (3)acquire and normalize historical customer purchasing data; (4) inputcontract terms and forecast financial performance of the term andcontract; (5) produce contract and term requirement documents; (6) markcurrent transactions by unique contract and term codes and produce adatabase to analyze contract terms; (7) produce performance informationfor supplier and customer personnel; (8) initiate customer discounts;and, (9) reconcile term requirements to term performance at or near theend of the contract. In one aspect of the invention, each of the abovefunctions are provided automatically or by implementation ofcomputerized processes. Some of the modules employed in a computersystem and software embodying the invention are discussed herein forillustrative purposes. These modules are particularly adapted foremployment by a representative of the supplier entity (e.g., airline).

Preferred System Configuration

FIG. 1 is a simplified system configuration diagram illustrating asystem 109 with which various steps or subprocesses of the inventivemethod may be implemented. These steps and subprocesses are implementedby executing a program that resides on a computer or application server103 (operable with a system administrator station 103 a) connected via anetwork 105 (and network access device 105 a) to a database server 101having retrieval and storage access to application databases 101 a. Thisallows the inventive processes(s) to be implemented in a client/serveror multi-tier configuration. In one embodiment, the program runs on acomputer. However, the program may also run on any other networkconnected device 107 capable of processing, displaying, and receivingdata and transmitting the data over the network (e.g., cellulartelephones, agent terminals, airline ticketing terminals, disklessworkstations, personal data assistants, etc.). The database(s) areconnected via a computer network 105 to the computer or the applicationserver 103. Although in the preferred embodiment, the database residesseparately from the computer, the database may reside on the samecomputer as the program. The computer network 105 shown is a local areanetwork 105, but may also be any type of network capable of handlingelectronic communications between two devices on the network (e.g., theInternet, Wide Area Networks, Cellular networks, Microwave networks,etc.). The computer network 105 may have any arbitrary topology and canbe comprised of a number of computers as well as network devices such asswitches, routers, gateways, firewalls, etc., and other resources suchas file servers, printers, etc.

General Method Of Generating a Purchasing Contract

FIG. 2 illustrates a flow chart generally describing a preferred set ofsteps for generating a purchasing contract according to the invention.The initial step of the method includes proposing a contract (201)between one or more supplier entities and one or more customer entities(although in the presently described method, the contract involves asupplier entity such as an airline and a customer entity such as a largenational corporation). The inventive method will require the creationof, access to, and/or storing preliminary information in one or moredatabases. For example, the method includes the initial step 203 ofcreating a contract Entity Database, which entails collectinginformation on the supplier and customer entities and storing datarelating to or representing this information in the Entity Database 303.Next, an entity Contacts Database 305 is created (205) which entailscollecting information regarding employee contacts within the customerentity and information on the employee within the supplier entityassigned to the contract, and storing this information as data in theentity Contacts Database 305. Further, certain ancillary databases 403are also provided (207) for purposes, which will be described below.

In another preliminary step 209, the proposed contract terms for thecontract are defined. Such contract terms may be similar to terms inother contracts made between the supplier and customer entities, orbetween the supplier and other customer entities. The contract termswill have associated therewith certain contract term attributes (e.g.,term performance criteria, discount, etc.). These term attributes arestored as a term data set 211, unique to the contract term, in the TermDefinition Database 315. Additionally, the proposed term will haveassociated therewith term performance rule(s), which will be explainedfurther below. These term performance rules are stored in a subsequentstep 213 in a Term Rule Database 313.

Upon establishing the above parameters for the contract and contractterms, certain steps are taken to forecast and qualify the contractterms for the contract, and thus to produce the contract. Accordingly,the next step in the method is the step 215 of collecting historicaltransaction data (i.e., by the customer entity for the same or similarproducts which are the subject of the proposed contract). As mentionedpreviously, such transaction data may be in a form that does notcorrespond with the product unit(s) that the supplier entity, itsprograms or systems is familiar with. In addressing this, the inventivesystem individualizes the transaction data sets which are collected(217). This may involve deriving one or more individualized transactionsfrom a parent transaction, or identifying less than a whole (percentage)of an individualized transaction from such a parent transaction. Aftercollecting the transaction data sets, these transaction data sets are,in a further step 219, converted into a standard format and stored in aTransaction Detail Database 307.

In what may be referred to as the next stage in this method ofgenerating the purchasing contract, certain of the proposed contractterms are qualified. In an initial step 221, one of the proposedcontract terms is selected. This is followed by a step 223 whereintransaction data sets in the Transaction Detail Database 307 areexamined such that those data sets which are identifiable or applicableto the proposed contract term are marked. Having identified thecollection of the appropriate transaction data sets, the proposedcontract term may be defined 225 and then tested. Further, theperformance of the term is forecasted using, as input, data from theidentified transaction data sets. The forecasting step generates certainperformance values or expected performance values and which are then (instep 229) compared to the appropriate term performance rules from theTerm Rule Database 313. If, based on this comparison, the proposed termis deemed qualified; the method assigns a unique term code to thequalified term (231).

Upon qualification (or non-qualification) of the first term, the methodfurther includes a step 233 of selecting another contract term, ifdesired, and qualifying that term.

After all of the selected proposed contract terms have been qualified,the method computes the financial result of the proposed contract withone or more of the qualified proposed contract terms (235). Based uponthe results of this computation, the contract is either approved ordisapproved (237). If the contract is approved, the contract and itscontract terms are produced (239). Based on the contract type, thesystem selects the correct contract and produces a shell contractincluding the correct name and address of the business entities andsignatories to the contract. Then, using data from the Contract TermDatabase, a term sheet is produced in standard language that mirrorsprecisely the term requirements stored in the computer.

The above is a brief, general overview of one general method accordingto the invention. The various subprocesses of this method and relatedmethods are described in more detail in certain sections of thedescription below and in respect to an airlines industry application.

Computer System Databases

FIGS. 3 and 4 illustrate the various databases which may be generated orutilized by a preferred system or software package according to theinvention. The following are introductory explanations of each database.

1. The Entity Database 303 contains fact information relating tocustomers, suppliers, distributors, airlines, alliance partners andother entities. Information on these entities include legal businessname, address, phone numbers, and tax number.

2. The Contacts Database 305 contains information relating to personsinvolved in transactions or contracts. These persons include persons whoare responsible for sales, customer management, or purchasing contracts.

3. The Transaction Detail Database 307 contains information relating toa collection of purchasing transactions by a customer arranged in acommon or standardized format. Each set of information or data may bereferred to herein as a transaction data set.

4. The Transaction Summary Database 309 contains summary informationrelating to certain detail transactions stored in the Transaction DetailDatabase. Creation and use of this database is described in detailbelow.

5. The Contract Registry Database 311 contains information relating tocontracts which have been created, i.e. through implementation of theinvention.

6. The Term Rule Database 313 contains information relating to operatordefined terms and include term requirements for minimum or maximumpurchase amounts, supplier share, or the number of units to bepurchased.

7. The Term Definition Database 315 contains information relating to theagreement for performance between the supplier and the customer. Some ofthe term attributes which are contained in the database includes itemssuch as term effective dates, performance requirements, discountinformation, etc.

8. The Term Performance Database 317 contains summary informationrelated to a particular term including such information as total unitcounts, total amounts, supplier shares, and requirement status.

9. The Payment Database contains information relating to payments madefor performing terms including payment schedule, start and end dates ofpayment period, payment amounts and discount amounts. Once the systemdetermines that the requirements for a term are met, the PaymentDatabase is used to process and record payments. These payments are alsoused in determining the actual discount paid and in computing the finalfinancial performance of the contract.

10. The Sales Goal Database 319 contains information relating tospecific performance related goals set by an entity such as a supplier.

11. The Supplier/Distributor Database 401 contains information relatingto entities which provide products (e.g., goods or services). SupplierEntities can be entities such as the supplier, distributor, andaffiliates of the supplier.

12. The Ancillary Database(s) 403 include one or more databases, whichcontain various information relating to flight segments, product andmarketing information, operating carriers, actual flight pricing,arrival and departure times, and other information. The ancillarydatabases provide information that is in the public domain, butfrequently contain data that are more reliable than data collected withthe transaction. When the data do not match, the most reliable source isused.

The above databases may be provided on a single electronic storagemedium or multiple electronic storage media, and linked/interlinked incommunication with one or more processors 301. Although, the databasesare shown as separate databases in the preferred embodiment, thedatabases may be created as a single database containing some, all orpart of the information found in the other databases. In any event, asystem or software embodying the invention will be able to create and/oraccess one or more of these databases.

Contract-Designated Transaction

Once the parties have agreed on their intent to negotiate a deal, thecustomer provides the supplier with detailed data for each purchase.Often these data are from disparate sources and arrive in incompatibleformats. The inventive system and method sequesters data into atemporary database before it normalizes the data into a commontransaction format. Data may reflect components of the actual purchasein which case the components must be constructed to reflect the actual(or whole) purchase, or data may reflect a transaction that comprisesmore than one product in which case the transaction must bedeconstructed to identify the product. In either case, the inventivemethod performs the subprocess of individualizing transactions ortransaction data.

Using the databases previously described, namely theSupplier/Distributor database 401, the ancillary database 403, theEntity and Contacts Databases 303, 305, the Contract Registry Database31 1 and the Term Definition Database 315, the inventive methodgenerates a new class or collection of data sets that ties thetransaction to the various aspects of the contract (see FIG. 4). Thefollowing data elements (attributes) may be acquired for each customertransaction: a descriptive code of the item purchased at the term level;the date and time of purchase; count of units purchased; net and grossamount of the purchase; supplier's unique code; and, the distributor'sunique code. These data elements are then used to lookup and deriveinformation from the databases identified in FIG.4. Upon lookup andderivation of information from the various databases, the new class ofdata 409-415 is automatically created. The new class of transactionaldata in the preferred embodiment contains or represents the followingattributes:

Product Description (405)

-   -   Product Code(s)

Supplier Code

-   -   Distributor Code    -   Unit(s)    -   Cost    -   Date & Time of Transaction(s)

Entity and Contact Information (407)

-   -   Supplier Entity

Supplier Contacts

-   -   Distributor Entity    -   Distributor Contacts    -   Customer Entity    -   Customer Contacts

Contract Information (411)

Contract Code

-   -   Term Code

Transactional data may be analyzed by contract criteria embodied in theTerm Definition database that includes the data elements which definethe contract term.

Term Requirement Information (413)

-   -   Market, Product, Class Requirement    -   Market Product, Class Discount    -   Begin and End Dates    -   Unit requirement and/or    -   Cost requirement and/or    -   Share requirement

Term Performance information (415)

-   -   Count    -   Amount    -   Share    -   Discounted and undiscounted amount

The system processes that create these data are illustrated in FIGS.5-18 and described below.

Input Contract Entities and Contacts

When an airline and a customer first discuss the possibility of a deal,the business entities in the proposed deal are identified. Entities mayinclude the corporate or agency customer, the airline, and the airline'spotential alliance partners. Facts on each party are required for thecontract such as legal business name, address, and tax number. Theinventive system stores this data in an Entity Database 303. Whilecontracts are between entities, individuals are responsible for themanagement of the contract. Airlines assign individuals who areresponsible for sales, customer management, and contracting. Likewise,companies assign individuals who are responsible for purchasing andcontracting. Information on these individuals are stored in the ContactsDatabase 305.

The flow charts illustrated in FIGS. 5A and 5B provide the creation (orupdate) of the entities and Contacts Databases 303 and 305. The processbegins with the operator inputting contract entity data (501) andinputting supplier data (503). Supplier entity and customer entity datamay include such information as legal name, address, phone, emailaddress, and web site. Further, the customer information may includesuch additional information as corporate division, industry, andapplicable sales region. A determination (505) is then made whetheranother supplier is to be added. If so, the operator inputs supplierdata for that supplier and for subsequent suppliers until no moresuppliers are to be added. The operator inputs distributor data (507),which is followed by a step 509 of determining whether anotherdistributor is to be added. This is followed by operator inputtingdistributor data for that distributor and for subsequent distributorsuntil no more distributors are to be added. The operator inputting datasource data (511) for a first data source, and, if it is determined(513) that there are additional data sources, for each of those datasources as well. Upon completion of the above steps, the entered data isstored in the Entity Database 303 (step 527).

FIG. 5B further illustrates the creation of a database 15 that may becharacterized as another Entity database. The Entity Contact Database305 contains information regarding the sales person responsible for thecontract, employees of the supplier entity and employees of the customerentity who are relevant to the contracts or contract terms. First, theidentity of the sales person responsible for the contract is entered(515). Next, the identity of the customer contacts are established(517). Then, employee or personnel contacts within the customer entityare identified followed by the step of loading or inputting contact datainto the Contact Database 305. Contact data may include such informationas the name of customer(s), address, phone numbers, and personalinformation for work and home. In the case of generating a proposedcontract and contract terms, the customer information will relate to apotential customer and the potential customer's employee(s).

In a second step 519, supplier entity employee data is loaded into theContact Database 305. This step is preceded by a step of identifyingsupplier entity employees who are responsible for the contract orproposed contract. This identification step preferably includesassociating a function and/or hierarchical position to each employee(e.g., sales supervision, contracting, payment). The contact data loadedwill, of course, include such information as name, address, phonenumbers, and personal information for work and home. The subprocess mayfurther include the step 321 of collecting and inputting distributorcontact data, when applicable. Additionally, the subprocess preferablyincludes the step 523 of inputting data source contacts and entering thenames or designations of responsible personnel for providing transactiondata on what has been purchased. All of these data is then stored in theContact Database (305) (step 525).

Establish Contract and Term Rules

The process of term qualification is conducted by matching or comparingthe financial results obtainable with a proposed contract term (e.g.based on historical transaction data) to predefined term criteria orterm rules. These rules are operator defined and may includerequirements for minimum or maximum purchase amounts, supplier share, orthe number of units to be purchased.

The flow chart of FIG. 6 illustrates in simplified form a process ofinputting, and thereby creating, term rules in the Term Rule Database313. In a series of steps, the minimum and maximum values for thesupplier share and the minimum and maximum values for unit count areinputted (601, 603). Then, the minimum and maximum values for grossrevenue amount and the minimum and maximum values for net revenue amountare inputted (605, 607). These steps may, of course, be performed invarious orders or sequences. The term rule definitions are then storedin the Term Rule Database 313 (step 609).

Normalize Data into Standard Transaction Format

It should be noted that, in one respect, the new class of data 409 (orcontract-specific transaction data set) is derived from at least threeother data sets: a transaction data set 307, entity data set 303,contact data set 305, and contract data set 311, and term data set 315.The creation of each of these data sets is further described below.

Airline data is derived from travel agencies, Global DistributionSystems, third-party data consolidators, or the airline's internalsources. The data is exported from distributor's sales informationsystems in different formats. A first subprocess of the inventive methodis to collect transaction data from such various sources and to convert(i.e., normalize) the collected transaction data into a transaction dataset 307 stored in accordance with a common format.

Data taken from the point of sale may not reflect the individual itemsmeasured in a term. Point of sale data may comprise individual productcomponents that must be constructed into the applicable unit productpurchased in a term, or point of sale data may comprise multiplecontracted products that must be deconstructed to identify theindividual product. In either case, the true item being measured by theterm must be constructed (or de-constructed) from the data provided.Airline systems store product data as flight segments. Using standardindustry practice, the many segments that comprise an itinerary areconstructed into origin and destination rows (ODs) reflecting the truedestination the traveler, or a group transaction may include manytravelers, in which case it is deconstructed to provide one transactionper traveler. Ancillary databases 11 are used to confirm the accuracy ofthe data, e.g. to determine, or correct, the designation of the carrier,the actual price of the flight, or the arrival and departure times.Typically, if the transaction data differ, data in the ancillarydatabase are given preference and written in. Once the data is convertedinto the standard format, it is loaded into the Transaction DetailDatabase 307. Then, refunds and exchanges are netted against theoriginal transactions so an accurate transaction count is maintained.Once the data is normalized, it is ready for contract term modeling andthe qualification of financial performance.

The flow chart diagram in FIGS. 7A-7C illustrates in simplified form apreferred data normalization process (i.e., a process of receivingtransaction data and storing at least a portion of the data inaccordance with a common format). The process begins with steps 701-711of inputting the following information: a count of units of productpurchased, a cost of units of product purchased, a unique code oridentifier for the product, a unique code or identifier for thecustomer, a unique code or identifier for the supplier, a unique codefor the distributor. Then, the input data or data set is compared withinformation in the ancillary databases 403 (step 713). If the input datadoes not match or correspond with data in the ancillary database 403 orsatisfy some other identifying criteria stored therein, the correctelements in the data set are then used to lookup and correct theincorrect elements (715). For example, if the value for the departuretime of a flight for the data source differs from value in theauthoritative ancillary database, the value from the ancillary databasewill be used to-over write the incorrect value.

If the input data does match, it is determined whether the productdescription represents the unit the customer purchased (717). If theproduct does represent the unit the customer purchased, then the processcontinues by loading data into the Transaction Detail Database 307 (step727). If the product does not represent the unit the customer purchased,then it is determined whether the transaction is a component of theproduct purchased (719).

If the transaction is found to be a component of the product purchased,the true product is first constructed from the data 721 before theprocess continues with the loading the data (527) into the TransactionDetail Database 307. If the transaction is not a component of theproduct purchased, it is determined whether the transaction is comprisedof multiple products (723). If the transaction is not comprised ofmultiple products, the data is loaded (727) into the Transaction DetailDatabase 307. If the transaction is comprised of multiple products,however, the true product is first deconstructed from the data (725).Either of the above series of steps is referred to as individualizingthe transaction data set collected for a transaction. For example, morethan one traveler may be indicated on one airline ticket. Each travelerrepresents one person traveling to that destination, and each travelermay receive a contracted discount. The system, therefore, creates andstores an individual transaction for each individual traveler (althoughone ticket was issued).

Now referring to FIG. 7C, the next step 729 in the method is determiningwhether the transaction is an exchange. If the transaction is found tobe an exchange, a pseudo refund is issued for the exchange (731). Arefund is issued to cancel the original transaction. This is criticalfor the true net transaction count. Then, in the next step 733, or ifthe transaction is not an exchange, it is determined whether thetransaction is a refund. If the transaction is a refund, the transactionis marked (735) as a refund and the original transaction is identified.Then, if the transaction is not a refund, the method proceeds directlyto loading the data (step 737) into the Transaction Detail Database 307.

Define Contract and Performance Term

Purchasing contracts are agreements between supplier and customer.Performance requirements for the contract are stated as one or morecontract terms (which are one of the contract attributes). In one aspectof the invention, the method enables the user to input and store theseterms in the computer as Structured Query Language (SQL) definitions orits machine language equivalent. Thus, by using the SQL definitions, thecomputer can readily compare the data elements associated with the termrequirements with corresponding data elements associated with a productpurchase, i.e., the transaction. When the data elements match, thecontract and term are automatically identified and marked. Each term mayinclude, as its attributes, a unique title, beginning and end dates forwhich the term is effective, performance requirements, discount amountand method (e.g., if term is satisfied), special purchasinginstructions, a user-defined code for the term, and identification ofthe distributors who are authorized to sell the product at the stateddiscount and how much they are compensated. Each contract is also givena unique code. Likewise, terms are given a unique code that groups themunder the appropriate contract. SQL definitions for a term are stored inthe Term Definition Database 315.

By using the term definition, the inventive method can identify eachtransaction or data set in the Transaction Detail Database 307 with adesignated unique contract code and term code, as well as theappropriate entity codes. In this way, a collection of contract-specifictransaction data sets are generated. Further, the inventive system andmethod provides a supplier entity an improved means of storing a uniqueclass of information pertinent to a supplier-customer contract and, ameans of generating, from data sets representing this information,transaction summaries and contract measurement reports.

FIGS. 8A-8I illustrate a method of defining a proposed contract and itscontract terms for use in a supplier-customer environment of the airlineindustry and designated for a customer such as large national company.The steps of the preferred method are implemented through variousoperations of inventive software by an operator representative of thesupplier entity. In FIG. 8, the method is initiated by accessing orstarting a Contract Definition module of the software and prompting theprogram to start a contract definition operation (801). The user selectsand enters a name of the proposed contract name (803) and then thebeginning and end dates of the proposed contract (805). Next, the userselects one of several choices of contract types provided on the module(807). The selections may include: agency; agency cluster; alliance;corporate; corporate cluster; meeting; or combinations of these. In yetanother aspect of the invention, the user may enter more than oneparticipating supplier (i.e., carriers) and identify these supplierswith the proposed contract. Among other things, this allows customerpurchases of tickets on carriers which are not the primary carrier forthe contract or customer but can be later credited to the customer andthe customer's contract. Then, the program assigns the proposed contracta unique identification code (811) and stores the contract description(which include the unique contract ID and the rest of the above-enteredinformation) in the Contract Registry Database 311 (813). Theinformation provided above is, therefore, accessible by using thecontract's unique identifier.

Preferably, the operator will access a second module to initiate thedefinition of the terms for the contract (815). In initial steps, theoperator enters a title or description for the term to be defined (817)and the beginning and end dates within which the term is to beapplicable (819). The system then assigns the term a uniqueidentification code (step 821) and stores a term description in the TermDefinition Database 315 (step 823).

Referring to FIG. 8C, in a subsequent stage of the method, measurementcriteria is defined for the contract term. The term measurement criteriais used to identify which historical transactions or records are to beidentified with the term and thus, used to measure the performance ofthe term. FIG. 21 A provides a screen shot of a module 2101 used todefine the performance measurement criteria of a proposed term. Afterinitiating the process (step 825), the operator enters the markets formeasurement (step 827) and then, the suppliers (step 829), products(step 831), and the classes (step 833) applicable to the term. Forexample, in the airline industry contract, markets are identified byflight origin-destination pairs, such as Washington, D.C.,-Chicago,O'Hare (IAD-ORD). Products are seats on the flight types which may beidentified as non-stop, one-stop, or direct. Classes of service, orcabin type, may be identified as first class, business, economy anddiscount. The term measurement criteria are then stored as a SQLstatement in the Term Definition Database 315 (step 835).

Next, the system queries whether measurement exclusions are to bedefined (839). These exclusions are used to identify transactions whichare not to be used in term performance measurement (but may, otherwise,qualify under the measurement criteria). Referring to FIG. 8D, themeasurement exclusion definition process is initiated by the operator.The operator defines the transactions to be excluded by specifying themarket(s) to be excluded (step 841), the supplier(s) to be excluded(step 843), and the product(s) to be excluded (step 845), and/or theclass(es) to be excluded (step 847). The resulting measure-on exclusioncriteria are then stored as an SQL statement in the Term DefinitionDatabase 315 (step 849).

If there are no exclusions to the performance measurement criteria to bedefined or all such exclusions have been defined, the operator beginsdefinition of the discount payment criteria (851) by accessing theappropriate payment criteria module (see, e.g., FIG. 21 C). The paymentcriteria provides the means by which to identify those transactions forwhich a discount is to be applied. The operator defines the paymentcriteria by entering the required market(s) (step 853), requiredsupplier(s) (step 855), required product(s) (step 857), and/or requiredclass(es) (step 859) for transactions to be discounted. The system thenstores this information as SQL statement in the Term Definition Database315 (step 861).

As with the term measurement criteria, the system also allows theoperator to define payment exclusions (865), thereby identifying theticketing transactions for which no discount will be applied. Theoperator initiates this process (see FIG. 8F) also through operation ofthe payment criteria module. Then, the operator enters the market(s)(step 867), the supplier(s) (step 860), the product(s) (step 871),and/or the class(es) (step 873) defining those transactions for which nodiscount is to be paid. Then, the payment exclusion criteria is storedas an SQL statement in the Term Definition Database 315 (step 875).

Term definition according to the invention also requires distributorrelated expenses to be accounted for. Airlines pay distributors, such astravel agents and credit card companies, commissions for takingreservations and selling airline tickets, and processing payments. Inthe inventive method and system, these payments can be accounted forwhen analyzing a contract term or contract. The user can define the termto include or exclude distributor commission, and to define theticketing locations that are permitted to sell tickets with thediscount.

Referring to FIG. 8G, the operator initiates definition of thesedistributor-related expenses or distributor compensation using the termdefinition module (step 877). For each distributor, the operator entersthe distributor's commission amount for each ticket (step 877), anydistributor override amount or additional incentive commission that ispaid or credited to the distributor (step 879), and any credit expense(i.e., credit card transaction fees paid to the credit card companies)by the distributor (step 891). The above are amounts ordinarilydeductible from revenue generated from the ticket transaction and notreceived by the airline supplier. Thus, these amounts may not bemeasured in the term's performance. The distributor compensationcriteria are then stored as an SQL statement in the Term DefinitionDatabase (step 883).

Now referring to FIG. 8H, the system further allows the operator todefine the discount payout criteria, still using the term definitionmodule (step 855). The operator defines the discount payout criteria byfirst selecting the payout timing (885), which may be selected to occurat the point of sale or at the end of one or more periods (stepdiscount). Next, the operator selects the performance or purchasecommitment requirement for the term, which may be entered as a share ofcount (total of customer's or supplier's transactions), share of totalexpenditure, or total count of transaction (or product units) or dollaramount for transactions (887). Then, the operator selects the discounttype to be employed, which may be a percent of the transaction(s)amount, a fixed price, or flat amount off (889).

If the payout timing selected is end-of-period, as queried to theoperator (891), the operator is prompted to define another step 893, inwhich case the operator returns to step 887 to select the performancerequirement for the next step. Otherwise, if the payout timing selectedis end-of-period, the operator is queried as to whether there is anotherpayout date and to define the applicable payout dates (894), until allpayout dates are defined. After the payout periods are defined, or ifthe payout timing selected is point of sale, the operator has the optionto enter codes used by the distributors to track product inventory inother management systems (896). The results from these criteria arestored as an SQL statement in the Term Definition Database 315 (step897).

With the above information for proposed contract and its terms, thefinancial performance of each term can now be tested or projected (seeprocess illustrated in FIGS. 11A-11B (step 898)) and the financialperformance of the overall contract may be tested or projected (seeprocess illustrated in FIGS. 12A-12B (step 899).

Marking Detailed Transactions

In an electronic environment wherein many purchases occur from manysources, and perhaps from many distributors, it is advantageous forsuppliers to be able to predict the financial performance, orprofitability, of their contracts. Accordingly, the present system andmethod, using criteria from the Term Definition Database (315), markseach transaction in the Transaction Detail Database with its uniqueentity codes, contact codes, contract code and term code. In doing so,the inventive method creates a new class of data or collection of datasets that ties the transaction to the various aspects of the contract(i.e., see FIG. 4). These contract-designed or contract-specifictransaction data sets are then used to create unique business processesthroughout the inventive systems and methods. For example, processes areemployed to qualify, monitor, pay discounts, and reconcile the financialperformance of the deal.

During the course of the contract, the customer agrees to provide datato the supplier to measure purchasing performance. These data areconsolidated and normalized in transaction data sets as described indetail earlier. As transactions are loaded into the Transaction DetailDatabase, the computer executes a routine that employs the SQL termdefinitions for the Term Definition Database 315 to mark each term withits unique entity codes, contact codes, contract code and term code. Theinventive method computes the summary totals for each term including thetotal unit count, total amount, supplier share for the period measured,and whether the term requirements were met or not. These data are loadedin the Term Performance Database 317.

In an exemplary subroutine for collecting current airline transactionsand marking the transactions applicable to a specific contract, thedatabases illustrated in FIG. 3 are utilized. The result of thesubroutine is an OD transaction table listing each OD as identified withthe contract information it meets. From the contract term table, thetime of purchase or end of term discount contract term ID and contractID are applied to the OD rows which are to be marked. The query IDdefines the OD rows which are to be counted towards the requirement(this value may be a percentage, count or monetary amount) of thecontract term. The financial query ID defines OD rows which are toreceive the specified discount of the contract term. It is noted thatthe query ID and financial query ID are separate and may definedifferent OD rows.

Furthermore, only the OD rows which are within the begin (departure) andend dates of the contract term, and which are associated with a companyor company clients specified by the contract term are marked. Thesubroutine begins by selecting from the contract table a contract thatis active and which has contract begin and end dates that encompassesthe subject date range for the ODs. Then, a temporary table is createdto hold all transaction numbers (associated with ODs) which match thecontract date and the ticket company and agency for the contract. Then,the ticket source company and the ticket customer company are identifiedbased on the contract type (i.e., Agency, Agency Cluster, Alliance,Meeting or Corporate, or Corporate Cluster).

FIG. 9 illustrates, in simplified form, a process of collecting currentdetailed transactions and marking certain of the detailed transactionswith the appropriate or designated customer, contract, and term codes,thereby generating a collection or set of contract-specific data sets.Initially, the system loads current normalized transactions into theTransaction Detail Database 307, and retrieves the appropriate termcriteria from the Term Definition Database 315. This begins thecomparison of each detail transaction row with the term criteria. First,the system retrieves a detailed transaction row (representing anindividualized transaction) from the Transaction Detail Database (901),and compares or matches data in the detailed transaction row with thecustomer criteria associated with the contract term (903). If thecustomer criteria is not met, the system retrieves the next detailedtransaction row (901). If the customer criteria is met, however, thesystem or program retrieves the next contract term from the TermDefinition Database (905). Then, the program compares the marketcriteria (step 907), the supplier criteria (step 909), and the productcriteria (step 91 1), which are associated with the contract term, withthe corresponding data from the detailed transaction row. Similarly, theprogram compares the class(es) criteria (step 913) and thedistributor(s) criteria (step 915) with the corresponding data from thedetailed transaction row.

If the program finds a match on all of the term criteria (917), it thendetermines whether the term is a point of sale term (step 919), in whichcase, the system marks the transaction with the appropriate contract andterm code (step 921). On the other hand, if the transaction is found tobe an end-of-period transaction, the transaction is appropriately markedas such and identified with the contract and contract term codes (923).After either case, the system retrieves the discount amount from theTerm Definition Database 315 (step 925). Then, the system computes andenters the undiscounted amount for the transaction (927).

At this point, the system inquires whether another transaction row (fromthe Transaction Detail Database) is available for marking (929). At theend of the process, all applicable transactions have been marked usingSQL criteria as defined and stored in the Term Definition Database 315.These data are unique to the invention because, among other things,these have been normalized and automatically designated by contract andterm.

Create Transaction Summary Database

FIGS. 10A-10B illustrates, in simplified form, a process of creating aTransaction Summary Database utilizing the unique transaction detailgenerated in the process illustrated by FIG. 5. For a given contractterm, in a first step of the process, the system retrieves pre-contractor historical transactions by customer identification code from theTransaction Detail Database 307 (step 1001). The system then retrievesthe appropriate contract term identifier and the appropriate select termstatements from the Term Definition Database 315 (as identified by theterm identifier) (step 1003).

With this information, the system is then able to select transactionsfrom the Transaction Detail Database which match the beginning andending date of the sample (1005). Further, the system selectstransactions by the designated distributor (1007). Using SQL criteriafrom the term definition, the system groups the transactions by market,supplier, product and class. With these groupings, the system computespreferred supplier(s) subtotal for transaction count, amount ofspending, average transaction amount, and share of total business (1011). Thereafter, the system computes other supplier(s) subtotals for thesame columns (1015). The results of these computations are stored in theTransaction Summary Database 309. FIG. 20 provides an example of ascreen illustration of a market analysis summary generated by theabove-described process.

The Transaction Summary Database from which the display module 2001 isderived is generated for a term entitled “US to US” as indicated in theterm column 2003. The table displayed contains summary market rows 2003identified by OD Pair and cabin type. These summary market rows 2003have each been identified by the specified term stored in the TermDefinition Database 315. Each market pair that qualifies for a term isgrouped by Markets, Directional Pair, and Cabin 2005. The total count offlights and amount spent by all suppliers in the market is tallied 2007.The system then computes the flight counts, amount of spend, and shareof flights for the designated supplier in the contract, the “host.”2009. Based on this data, the system can compute the variance betweenexpected share, “NAS” and Actual Share 2011. These summary, historicaldata may now be used to forecast term performance (see FIG. 1I) andforecast contract performance (see FIG. 12).

Forecast Term Performance

FIGS. 11A-11B illustrate, in simplified form, a process of generatingthe Term Performance Database 317 for a proposed contract term. In aninitial step 1101, the system retrieves a customer's data from theTransaction Detail Database 307. Customer data from the Market AnalysisSummary which match the proposed term requirements stored as an SQLstatement are selected (1103). Next, purchasing totals are computed forall suppliers including product count, amount of spend, and averagetransaction price (1105). Next, purchasing totals are computed for thesupplier for the designated contract, the “host” supplier, includingproduct count, amount of spend, average transaction price, undiscountedamount, and its share of the products purchased (1107).

The system next retrieves the proposed term requirements for thecontract term from the Term Definition Database. The system forecaststhe customers estimated number of transactions, gross revenue,supplier's resulting share of business, displacement of existingnon-discounted business, discount dilution due to lost revenue from thediscount, and net profit (I 109). The system then computes the sameresults without the discounted term to forecast financial resultswithout the proposed deal (1111).

Financial minimum requirements for all terms are retrieved from the TermRule Database 313 as previously defined in FIG. 6. The forecastedresults of the term are compared to the term rules on such criteria asminimum number of transactions, net profit, supplier share of business,or other financial ratios (1115). The system informs the user whetherthe proposed terms meet the requirements of the term rules (1117). Ifthe term fails, the user may elect to revise the term (1119) orover-ride the rule and accept the term. Once the term is accepted, thefinancial results of the forecast are stored in the Term DefinitionDatabase (1123).

A screen print of the results of the financial analysis of the proposedterm is displayed in the Financial Terms tab in FIG. 21 C. The termname, date range, and distributor compensation method are identified inthe under the term column 2119. The requirement for the term, includingpayment method, requirement type and amount, and payment type and amountare defined 2121. The financial projections for the term may becalculated from the Transactions Summary Database 309 (FIG. 10). Theanalysis compares results for no discount, current discount, andproposed discount 2123. The financial results are tested for minimumProfitability, Share, and Volume (2121) to determine if these meet therules in the Term Rule Database 313.

One advantage provided by the present system and method is that itenables suppliers to measure customer contract performance byuser-defined periods such as by month, quarter, and annually. Based uponthe Term Performance Database produced from data derived from theTransaction Detail Database, the inventive method computes an analysisthat provides the period average, contract-to-date average, and comparesthese amounts with the performance requirement. The system then alertsthe user of any non-performing term; that is, any term that is notmeeting the requirements stated of the contract.

Forecast Contract Performance

FIG. 12A-12B illustrates, in simplified form, a method for forecastingcontract performance. This is accomplished by analyzing the overallfinancial results of each of the combined individual terms. The systemfirst retrieves the forecast results of each term from the TermDefinition Database 315 (1201). Term totals are computed for allsuppliers including product count, amount of spend, and averagetransaction price (1203). Term totals are then computed for the supplierfor the designated contract, the “host” supplier, including productcount, amount of spend, average transaction price, undiscounted amount,and its share of the products purchased (1205).

Using the term totals, the system makes two sets of forecasts. TheSystem forecasts the customer's estimated number of transactions, grossrevenue, supplier's resulting share of business, displacement ofexisting non-discounted business, discount dilution due to lost revenuefrom the discount, and net profit (1207). The system also computes thesame results without the discounted term to forecast financial resultswithout the proposed deal (1209).

Financial minimum requirements for the contract are retrieved from theTerm Rule Database 313 (as previously illustrated by way of FIG. 6) instep 1211. The forecasted results of the contract are compared to thecontract rules on such criteria as minimum number of transactions, netprofit, supplier share of business, or other financial ratios (1213).The system then informs the user whether the proposed contract meets therequirements of the contract rules (1215). If the contract fails, theuser may elect to revise the contract terms (1219) and return to theterm definition process (see FIG. 6) or over-ride the rule and acceptthe contract. Once the term is accepted, the financial results of theforecast are stored in the Term Definition Database (1221).

A screen print 220 of the results of a financial analysis of a proposedcontract is displayed in FIG. 22. Each term is identified under a Termtitle column 2201. Columns for the requirement for the term (2205) andmeasurement method (2707) are provided. Also, a financial projectionColumn 2211 is made for each term including Incremental Revenue andPercent. Detailed financial results and ratios are displayed for thecontract in another area 2213 of the screen. The module also provides anindication box 2215 for the financial results of testing on minimumProfitability, Share, and Volume 2215 to determine if they meet therules in the Term Rule Database 313.

One advantage provided by the present system and method is that itenables suppliers to measure customer contract performance byuser-defined periods such as by month, quarter, and annually. Based uponthe Term Performance Database produced from data derived from theTransaction Detail Database, the inventive method computes an analysisthat provides the period average, contract-to-date average, and comparesthese amounts with the performance requirement. The system then alertsthe user of any non-performing term; that is, any term that is notmeeting the requirements stated of the contract.

Produce and Distribute Contracts and Terms

The flowchart diagram in FIG. 13 illustrates preferred procedural stepsfor the production and distribution of performance information. Theprocess begins with the step 1301 of gathering information from theEntity Database 303 and Contact Database 305 and placing these in acontract shell (such as a word processor template file). The inventivesystem then produces a paper copy of the contract agreement (1303). In asubsequent step 1305, the term values are gathered from the TermDefinition Database 315, and then written into the contract term sheet(1307). A copy of the contract and terms sheet are presented to thecustomer who may decide to renegotiate agreement or accept the terms ofthe agreement (1309). If the agreement is renegotiated, the termdefinition process begins again FIG. 8. If the agreement is accepted,the contracted is activated in the system (1311).

Audit Discounted Transactions

Suppliers run the risk of distributors applying the discount from onecustomer to an unauthorized customer. The system protects against theabuse of discounts by auditing each transaction to determine if thediscount has been applied to the correct customer, discount, andproduct. The audit begins by retrieving a transaction and the code ofthe distributor(1401). The system reads the pertinent data thedistributor and customer to the approved terms by contract, supplier,market, product, and class (1403). The system then determines if thetransaction was sold by the approved distributor (step 1406), to theapproved customer (step 1407), for the correct market (step 1409), forthe correct product (step 1411), with the correct discount code (1413),and if the discount take was correct (1415). If any of these criteriafail, the system marks the record with the corresponding audit numberand indicates the correct term code and discount amount (1419).

Measure Actual Contract Performance

Once supplier and customer have agreed to the contract, on-goingmeasurement of performance is critical to the success of the deal. FIGS.15A-15B illustrate, in simplified form, how the inventive systemmonitors and may measure actual contract performance. The process beginswith the detailed transactions being identified and marked by customer,contract, and term as described in FIG. 9 (step 1501). Performance istracked by contract period, such as by month, and from contract begindate to the current date. All of a customer's transactions are groupedby contract and term (1503). This collection includes transactions fromthe contracted supplier and non-contracted suppliers and provide grandtotals for product counts and amount of spend (expenditure) which areessential for computing share of business (1505). The system nextcomputes the customer's purchasing figures including count of productspurchased, amount of spend, designated supplier's share of products andspend, the discounted amount for purchases, and the undiscounted amountwhich will be used to compute the amount of savings provided to thecustomer (1507). The results of the computations are stored in summaryfashion in the Term Performance Database 317 (1509).

The system next gathers the term requirements from the Term DefinitionDatabase 315 (step 1511 ). Using those term requirements, the systemtests the term requirements against the actual summary results for theterm stored in the Term Performance Database 317 (step 1513). If thecontract to date summary results indicate that the term has not met theterm requirements, performance for the term for the period is marked asnot fulfilling in the Term Performance Database (157). If the contractto date summary results indicate that the term has met the termrequirements, performance for the term for the period is marked asfulfilling in the Term Performance Database (1519).

The system then gathers the contact information for the parties of thecontract from the Entity Database 303 and Contacts Database 305 (step1521). An electronic message, such as an email or fax, can then beprepared and sent to inform the parties of the contact status (1523).

The Term Performance Database 317 is the major outcome of theabove-described process. This summary level database may be used forquickly monitoring and evaluating term performance, and for theproduction of reports and financial analysis.

Reconcile Final Contract Performance

At the end of the contract, the final performance of the terms iscomputed. The inventive system and method facilitates the determinationof which terms are fulfilled and which terms failed and, additionally,provides variance and financial impact. Final financial performance ofeach term may be further compared to a term summary prediction model. Inthis way, a recommendation as to how future contracts can be improvedfor suppliers and customers may be provided. Results may also becompared to the goals stored in Sales Goal Database 19 to measure salesperformance. Results of this analysis are distributed electronically tothe contacts identified and recorded in the Contacts Database 305.

FIG. 16 illustrates preferred procedural steps for the finalreconciliation of the terms and contract. The process begins with theoperator or program retrieving end of period results for the contractterms and the contract; from the Term Performance Database 317 (step1101). Also, the term requirements for the particular terms areretrieved from the Term Definition Database 315 (step 1103). The resultsfrom the Term Requirements Database and the Term Performance Databasecan now be compared. In particular, the inventive system computes thevariance between the term results and the term requirements (1605), forsuch information as transaction count, transaction amount, percentshare, gross profit and net profit. Based upon this comparison, thefinal status of the contract is then marked (1607). In this step 1607,the contract may be marked with the status of FULFILLED, PARTIALLYFULFILLED OR FAILED TO FULFILL. Next, the contract results are marked(1609) in the Sales Goal Database for the measurement of internal sales,and the final contract reconciliation reports are produced (1611).Reconciliation reports are then distributed to entities in accordancewith the information from the Entity Database and the Contact Database(1613).

Payout Discount

As a contract period comes to a close, the system enables a supplier toreconcile a customer's performance with the contract requirements andprepare the payout of the discount. For example, airline customers takea discount either at the point-of-sale when a ticket is purchased orwhen the airline pays on the deal at the end of a designated term. Theinventive system and method provides for confirmation whether a termrequirement has been met, the amount of discount that has been taken atthe point-of-sale, or the amount that is due to the customer at the endof the term. FIG. 17 illustrates preferred procedural steps for thisprocess.

The process begins by determining whether the term is performing (1701).The system is able to do this by examining whether the term is marked inthe Term Performance Database 317 as performing or failing (see markingstep 903). If the term is performing, the step 1707 of paymentauthorization is conducted. If the term in not performing, the term maybe modified or canceled in a subsequent step 1703. The inventive methodalso generates payment documentation (1707) and records payments in aPayment Database (step 1709). Contract performance information isproduced from the Term Performance Database 317 and is distributed tothe contacts identified in the Contact Database 305. These reportsprovide the performance status of each term and may be distributed toboth airline and customer contacts electronically and automatically.

Manage Sales Goals

Suppliers measure the sales staff performance against predeterminedgoals established for a period (such as a year). Goals may represent thesum production of all contracts managed by that sales person. Bytotaling the summary results of the contracts assigned to a salesperson, the inventive system determines the fulfillment status of asales person's contracts, whether or not their goals have been attained,and the variance to goal. Similarly, suppliers can measure productionand contact results by region, contract type, or industry. For purposesof example, FIG. 18 describes in simplified form the process used tomanage sales person's goals.

A process for providing the above begins by identifying the sales person(1801). The identified sales person is matched to the contracts forwhich he or she is responsible (1803). The system then retrieves theperformance results from the Term Performance Database 317 (step 1805)and retrieves the sales goals for the sales person from the Sales GoalDatabase 319 (step 1807), then computes the variance between actual andgoal (1809). The results of this comparison are stored in the Sales GoalDatabase 319 (step 1811). Once the data have been stored, reports formonitoring past performance and projecting future goals are run (1813).

Exemplary Database Tables

FIGS. 3 and 4A-4B illustrate an exemplary set of database tablesgenerated by the system. These tables are used in the softwareapplication of the inventive method for the airlines industry. In oneapplication, the tables are used in analyzing a proposed contractbetween an airline (supplier entity) and its clients (customer entity).These tables and the processes which employ and/or generate these tablesare described in more detail below in the description of a softwareapplication in the airline industry. Table Name Description EntityDatabase 303 The contracting entities including airlines, customers, andtravel agencies. Data includes such elements as business name, legalname, and addresses. Contact Database 305 The individuals responsiblefor the contracted relationship between the customer and airline.Transaction Detail Detailed, normalized transactions, or flights,Database 307 sold by the airline and purchased by the company as acondition of contracting. Transaction Summary Summarized data derivedfrom the Database 309 Transaction Detail Database, identified bycontract term in the Contract Registry Database and Term DefinitionDatabase, reflecting purchasing totals by contract term. ContractRegistry Data associating the entities and parties in the Database 311contracted relationship. Term Rule Database 313 The supplier-definedrules for the judging the minimum financial performance of termsincluding count of products, amount of spend, or share of business.Rules are stored using SQL language to test the acceptability of termdefinition. Term Definition The terms of contract including products tobe Database 315 discounted, performance measures and type, and discounttype and amount. Terms are stored in SQL to be used to identify and marktransactions as they are loaded in the Detail Transaction Database. TermDefinition A summary database that includes totals for Database 317flights, amount of spend, and share by customer. The Term PerformanceDatabase also tracks whether or not a term is performing. Sales GoalDatabase 319 The sales goals established for the airline's sales personsstored as either a number of products, amount of spend, or shareperformance.

The Entity Database 303 and Contact Database 305 work together to storeinformation on the business entities, such as customer, airlines, oragencies, and the individuals that participate in contractingrelationships. In an airline-contracting environment, entities wouldinclude corporate customers, a contracting airline, often an airlinealliance partner, and one or more travel agencies. Entities can changeroles. For example, an agency serving as a distributor for one customermay also be a direct customer of the airline. This is why the databasepermits entities to change their role in any given contractingsituation. Contacts are associated to the entities for which they work,such as a corporate customer or an airline employee. Many contacts maybe associated with any business entity. Contacts may also move betweenentities if their job changes. By associating contacts and entitiesdynamically, the system creates a history of the business relationshipwith both business entities and the contacts that work for them.

Detail transaction data are derived from many sources including travelagencies, credit card providers, or customers. Since airline data arrivein different formats, they are normalized into a standard origin anddestination structure. For example, a two-segment flight originating inAlbuquerque and connecting in Houston and arriving in New York LaGuardia airport would be written as one origin and destination(ABQ-IAH-LGA). Errors that are common in airline data are corrected toensure reliability. Last, the true amount paid for the destinations iscomputed from the segment detail and verified with actual the actualticket amount. These data form the foundation of the Transaction DetailDatabase 307.

Once a contract has been established between an airline and itscustomer, transactions are marked by customer, contract, and contractterm as they are loaded FIG. 9A-9C. Customer identification in theairline industry is particularly difficult since travel agencies that donot disclose their customers account numbers. The system maintainslook-up tables matching agency account numbers to the corporateidentity. Once the company has been identified, the system uses the TermDefinition Database 315 to determine if the transaction qualifies for acontract. Using the structure query language description of the term,each transaction is processed. Where the transaction matches the termdefinition, it is market by contract and term code. These new, detailedtransactional data, normalized in structure and designated by contractand term, are the foundation of the system.

The Transaction Detail Database includes, but is not limited to, thefollowing data elements: Name Description Transaction Number The numberof the transaction. OD1 The first ODPair in the itinerary. OD2 Thesecond ODPair in the itinerary. Uni1 The first directional OD pair. Uni2The second directional OD pair. Carrier Code The industry standard codefor the airline. Service Class The class of service flown. Fare BasisCode The carrier's code for the flight. Ticket Designator The uniquecode often put in by travel agents to identify a contracted fare. CabinThe plain language identification of the cabin type: Supersonic, First,Business, Economy, or Discount Depart Date and Time The departure dateand time of the flight. Arrive Date and Time The arrival date and time.OD Amount The gross amount paid by the passenger for the flight,including taxes and surcharges. Net OD Amount The net amount paid by thepassenger for the flight, excluding taxes and surcharges. Distance Thepoint to point distance flown. Elapsed Minutes The point to point timefor the flight. Cross Boarder Identifies transactions that containflights that cross country boarders. Company ID The unique number givento designate the customer. Contract ID The unique number given todesignate the contract. Term ID The unique number given to designate theTerm of the contract. Discount The amount of discount applied to thetransaction.

The Transaction Summary Database 309 contains summary transaction dataderived from the Transaction Detail Database above. Summary data aregrouped by market, cabin, and class of service and are used for ananalysis performed for a contract (i.e., used in qualifying or otherwiseanalyzing the performance of a contract). In this particularapplication, there is one market analysis per contract and thus one setof definitions for each contract. The table includes columns for thecontract ID, the analysis begin date, the analysis end date, and the topnumber of markets which are included in the analysis. The supplier oftenlimits the contract analysis to certain of the customer's markets or topmarkets. Sometimes, only these top markets are used in the analysis.Specific discounts are determined for these top markets while a generaldiscount is applied to all other markets.

A Transaction Summary Database contains a summary of origin anddestination rows which are those detailed transactions applicable to oridentified with the proposed contract (see e.g. FIG. 20). After the topnumber of markets for a customer is identified, this table is generatedfor those markets. Among other information, this table contains rows ofOD Pairs and Directional Pairs and includes the number of flights,amount, and share of flights for the designated carrier or alliance andother carriers. With this data available, terms may be applied to groupsof markets and a forecast can be made using the proposed terms and tojudge the financial results of the contract.

Other columns of information provided in Transaction Summary Databaseinclude sums or totals for all ODs for the company of the contract andin the date range of the market analysis. Information includes sum ofthe net OD accounts (system flights), sum of the OD amount (systemamount), sum of the net OD count for ODs flown by the contractingcarrier or carriers, sum of the undiscounted OD amounts, amount paid outin back end discounts, and front end and back end carrying costs anddilution costs. Other columns of information include market share,weighted average manage share, commission percentage, overridepercentage, carrying costs, high and low fares, and other financialinformation.

The Data Transaction Summary Database includes, but is not limited to,the following data elements: Name Description OD1 The ODPair1 that thisresult is computed for. OD2 The ODPair2 that this result is computedfor. Uni1 The UniPair1 that this result is computed for Uni2 TheUniPair2 that this result is computed for Cabin ID The ID of the cabintype that this result is computed for Service Class The class of servicethat this result is computed for Front End Term ID The term ID assignedif the row meets the requirement or discount query criteria for a frontend (time of ticketing) term. Once a term ID is assigned, it cannot beoverwritten by a subsequently defined term. If the term ID is zero, thenno term is assigned. Front End is Discounted Flag determining whetherthe discount criteria or the requirement criteria for the front endcontract term is met. Back End Term ID The term ID assigned if the rulemeets the requirement or discount query criteria for a back end term.Back End is Discounted Flag determining whether the row meets thediscount criteria or the requirement criteria for the back end contractterm. Market Type Code The unique, user-defined code that enablessuppliers to group markets for the purpose of analysis.

Thus, the Transaction Summary Database provides a collection oftransactions (ODs) applicable to a current or proposed contract and itscontract terms. The table also includes all the pertinent attributes ofthose transactions. Using some of these attributes as input, theperformance of the proposed or current contract may be analyzed andvarious performance reports generated. FIG. 19 depicts a softwaredisplay module 1901 providing some the information in the MarketAnalysis Summary table.

The Contract Registry Database 311 contains information on all thecontracts between the supplier and its customers. The Contract RegistryDatabase includes, but is not limited to, the following data elements.Column Name Description Contract ID The unique system generated ID forthe contract. Company ID ID identifying the company to which thecontract applies. Contract Type ID ID of the contract type, e.g.,agency, agency cluster, alliance, corporate, corporate cluster, andmeeting. Contract Status ID E.g., active, canceled, pending. ContractBegin Date Beginning date for a valid contract. Contract End Date Enddate for a valid contract.Thus, given a contract ID, the company, contract type, status, and beginand end dates may be associated the Contract table.

Airlines often permit field sales persons to define their own contractterms. When this occurs, contracting officers require a means to ensurethat the deal falls within acceptable parameters. The applicationestablishes these parameters within the Term Rule Database 311. Rulesmay be established for any financial or performance criteria measured inthe data. For example, performance may be measured by a required totalnumber of flights within a market, or by a required amount ofexpenditure, or a required share of business. Performance ratios mayalso be entered, such as profitability, dilution, or fair market share.As terms are modeled using historical data summarized in the TransactionSummary Database, rules from the Term Rule Database are applied. Usersare notified when the parameters of any term fail the test of a rule.

The Term Definition Database 315 also includes columns which identifywhether the contract is net of commission, net of override, and/or a netof credit card commission. Whenever any of these flags are triggeredduring a contract analysis, a payment or deduction to a transactionamount (or contract amount) is usually effected thereby decreasing thetotals for that contract. The database also contains information of thepayout schedule table for back end contract terms. Back end deals may bepaid out incrementally throughout the contract. The columns in thisdatabase table include contract ID, contract term ID, payment date, payperiod start date, requirement achieved for the pay period, actualdiscount percentage paid for the period, and payment amount. Whereback-end payouts are based upon performance steps, the Term DefinitionDatabase contains data these steps for back end contract terms. Back enddeals may pay different amounts based on the share that is received.This database includes columns for contract ID, contract term ID, steprequirement, and step discount. Note that the step requirement of valuemay be a percentage, account or dollar amount, depending on therequirement measure ID of the term. Similarly, the step discount may bea percent or amount of discount per ticket for this step. The DataDefinition Database includes, but is not limited to, the following dataelements. Column Name Description Contract ID System generated unique IDfor this particular contract. Contract Term ID System generated uniqueID for this particular term of contract. Term Begin Date Starting Datefor which this particular term is effective. This date is used whenmarketing ODs. Term End Date The ending date that this term iseffective. This date is sued when marketing ODs. Discount Type ID The IDof the discount type for this term, e.g., front end (time of ticketing)or back end. Discount Measure ID The unique ID for this measure, e.g.,by amount, no discount, one-way base fare, or percent. Discount Percentor amount of discount per ticket for this term. Requirement Measure IDThe ID of the measure for this term, e.g., by amount, flight, norequirement, share of amounts, or share of flights. Requirement Therequirement value for this term. This value may be a percentage, a countor dollar amount, depending on the measure ID. Query ID The ID of thecriteria for the query which defines the OD rows which count towards therequirement of the contract term. The corresponding SQL is stored in theterm definition database. These rows are marked with the contract termID. Financial Query ID The ID of the criteria for the query whichdefines OD rows to receive the discount of the contract term. This queryis stored in the Term Definition Database. These rows are marked withthe contract term ID.

Upon the implementation of a contract, transactions are marked bycompany, contract, and term in the Transaction Detail Database. Fromthese data, a summary database is created, the Tern Performance Database317, that is used to monitor the performance of contracts. Grouping 10the data by term within periods, the system compiles totals required forthe measurement of contract performance. These data include totalflights, total amount of spend for all carriers. Total flights, amount,share, discounted and undiscounted amounts are then determined for thecontracted carrier. Comparing these totals to the requirements stored inthe Term Definition Database, the system determines whether or not theterm or contract is fulfilling. The data elements in the TermPerformance Database includes, but is not limited to, the following dataelements. Column Name Description Contract ID System generated unique IDfor this particular contract. Contract Term ID System generated uniqueID for this particular term of contract. Contract Period Measurementperiod within the contract, such as a month or quarter. System FlightsTotal number of flights for all suppliers that meet the term criteria.System Amount Total number of spend for all suppliers that meet the termcriteria. Host Flights Total number of flights for the host supplierthat meet the term criteria. Host Amount Total for the host suppliersthat meet the term criteria. Host Flights Share of host flight of totalflights. Share Host Flight Share of host flights amount. Amount StatusStatus of contract performance for the period; that is, whether thecontract is fulfilling or not fulfilling.

The Sales Goal Database 319 stores sales goals for an airline's salesstaff. These goals may be expressed as a number of flights, amount ofspend, or share of business, or any combination of these. Companies areassigned to sales persons to manage contracted relationships. At the endof a performance period, the actual production of the contracts iscompared to the sales-person's goals to measure performance. Since salesgoals are stored for any period, performance may be measured year overyear or projected for an upcoming year.

While these nine tables server as the foundation of the inventivesystem, other tables are required for look-ups, indexes, and scheduling.All data are linked to provide an application for the comprehensivemanagement of contracted relationships. An example of an airlineapplication follows.

More on Exemplary Airline Application

The present description now provides more specific examples ofapplications of various portions of the inventive system and method inthe airlines industry is provided. The various processes are implementedby a system and software operable by an operator-employee of the airlinecarrier or a distributor, and used to analyze proposed and currentcontracts and to generate reports therefor. The software applicationpreferably includes several modules which are user-interactive togenerate and analyze proposed contract and terms. FIGS. 19-22 providescreen shot examples of these.

FIG. 19 provides an illustration of a normalized detailed transaction1901. All of the data provided must be constructed from multiple datasources including travel agency invoice data and airline segment data.Ticket level data are typically constructed primarily from travel agencyinvoice data 1903. This data also provides the information to identifythe customer 1905. While customers may have many agency account numbers,the system groups these many accounts into one, discrete customernumber. One number is essential for purposes of mapping a customer to adesignated contract. The bottom half of the record includes an exampleof one origin and destination 1907. These data are derived from airlinesegment data. Segments are the individual flights a passenger flies toreach a destination. In the example, the passenger departs fromAlbuquerque, connects in Houston, and arrives in Atlanta. While thepassenger flew two segments, he actually bought one origin anddestination, ABQ-HOU-ATL. Normalized data in the origin and destinationdata format is essential because it reflects the product the customerbought under the contracted relationship FIG. 7A-7C. Once data thatidentifies the product has been created, the data may be tested todetermine if it qualifies for a contracted discount. Using SQL criteriastored in the Term Definition Database 315, each origin and destinationloaded into the system is tested to see if it qualifies for a term. Ifit does, the transaction is marked by contract and term 1909, asdescribed in the data marking procedure FIG. 9A-9C. Last, the systemdetermines the true origin and destination value by assessing, and ifneeded correcting, the segment amounts to ensure that the segments andall other charges equal the full ticket amount. This step provides thetrue origin and destination cost 1911 which is essential to determinethe amount of discount.

FIG. 20 provides an illustration of the Market Analysis Summary module2001. Prior to developing the terms of a contract, the user polls theTransaction Detail Database 31 to create a Market Analysis Summarytable. These data include a column in which the term name will beapplied (2003), the Market (2005), the total Flights and Amount for allcarriers in the market (2007), the Host's Flights and Amount (2009), andthe Host's share of businesses (2011). As terms are constructed, termsare applied to the Market Analysis Summary, and the Term name is writteninto the Term name column. Terms are individually added until allmarkets that the airline wants to discount are committed. Data from theMarket Analysis Summary is used to forecast the financial performance ofthe term.

In an airline industry software application, the inventive system andmethod enables the user to define individual contract terms whichprovide for discounts to be paid for tickets booked to specifieddestinations. The definition of individual contract terms is performedin the Term Definition Module of the software (see FIG. 21A-21C). Thesystem process is described in detail in FIG. 8A-81.

From a list of term criteria, the user or operator first selects thecriteria for the Discount 2103. By selecting market and cabin criteria,the system displays the appropriate form for the user to fill in thediscount requirements 2105. Each term comprises different combinationsor carriers, markets, and cabin. The results of the discountrequirements are displayed in plain language in the Term column 2107.The system then converts the criteria into a structured query languageformat stored in the Term Definition Database 315 that is used by thecomputer for identifying and marking flights that apply to the term. Thediscount requirements are stored as SQL statements that will be appliedto the historical data stored in the Transaction Summary Database 309 toforecast the term's financial performance, and to mark new transactionsloaded into the Transaction Detail Database, as they are loaded into thesystem. The use of the computer to identify these terms eliminates therequirement for manual input of unique supplier codes and also enablesthe matching of the term for other carriers.

In a next stage, the user defines the Measure-on 2109 requirements, orwhat the customer is expected to produce for the discount defined above.In consideration of these commitments, the airline agrees to pay adiscount. In the inventive method, the user defines the discount as apercent off of the actual fare, a monetary discount per ticket, or adesignated flat fare. Discounts to be paid to the customer are alsodefined by way of the Term Definition Module. By selecting the form ofpayment, either at the point of sale or end of contract period, the usermay then define the type and amount of discount and performancerequirement. At the completion of the Measure-on screen, the results arestored as SQL statements in the Term Definition Database 315.

In a subsequent stage, the user selects the financial requirements ofthe term. FIG. 21C depicts the Term Definition Mode 2119 and theFinancial Requirements selection mode 2121. Selection windows providefor selection of the various term attributes, including term period,agency compensation, and discount parameters. A forecast of the term'sperformance is displayed in window 2125. The process is described indetail in FIG. 11A-11B. Once the financial forecast is complete, a box2123 displays alerts if the term falls below the required minimumsestablished in the Term Rule Database 313 as described in FIG. 6. Bymodifying requirements for share and levels of discount, the operatorcan adjust the financial performance of the term until it satisfies theTerm Rule requirements.

Once the individual terms have been defined, the system produces afinancial forecast of the contract in its entirety in the ContractPerformance screen 2201. Each term is identified by name 2203,requirement 2205, method of performance measurement 2207, and thediscount to be provided 2209. Based upon the financial results storedfor each term in the Term Definition Database 315, the system forecaststhe incremental revenue above current revenue for the term 2211 and itspercentage. Ratios judge the financial benefit of the term includeprofit/dilution and fair share ratio. The system displays a forecast forthe overall financial performance of the contract including No DealRevenue, Current Revenue, and Proposed New Revenue. Based upon thesefigures, the system calculates the Net Profit of the deal 2213. Theoverall worthiness of the contract is tested with criteria establishedin the Term Rule Database 2215. Where profitability, share, or volumefails a test, the system displays an alert. Based upon actual,normalized data, the system has provided a forecast of the financialperformance of each term and the overall contract.

After the contract has been implemented, the inventive system uses datafrom the Transaction Detail Database 307 to construct the TermPerformance Database 317 described in step FIG. 15A-15B. The operator myrun reports that display the actual financial performance of a contractat any time during or after the contract period 2301. The reportdisplays by Company, Contract, and term the financial results of thecontract 2303. The. Host Flights and Market Share columns reveal thenumber of flights and the Host's share of the total flights 2305; theHost Net Amount and Market Share reveal how much has been spent and theHost's share of the total expense 2307. The Measure column describes themethod of measuring the customer's performance and the requirement 2311.The actual performance compared to the requirement provides thepercentage Variance between actual and requirement 2313. Based uponthese results, the system determines whether or not the term has beenfulfilled or not with a “yes” or “no” designation 2315.

The overall results of the contract may also be assessed using the sumof the term requirements. The Minimum flights amount is computed andcompared to the actual Contract Performance 2317. The variance betweenthe two described by flights displays the overage or underage ofperformance 2319. Likewise, the difference between the minimum amountand actual amount displays the variance by amount. In the finalanalysis, using the variance of flights and amount, the systemdetermines whether or not the contract is fulfilling 2323.

The foregoing description is presented for purposes of illustration andis not intended to limit the invention to the forms disclosed herein.Although the description is primarily directed to an application of theinventive system and method to the airline industry, the system andmethod may be employed in other common carrier applications and in otherindustries. For example, the system and method may be adapted forapplication in other volume buying contractual relationships and withrespect to other services and/or products (e.g., purchase of rawconstruction materials or utilities). Variations and modificationscommensurate with the above teachings, and the skill or knowledge of therelevant art, are within the scope of the invention. The embodimentsdescribed herein are further intended to explain the best mode known forpracticing the invention (i.e., as applied to the carrier industry) andto enable others skilled in the art to utilize the invention in such, orother, embodiments and with various modifications required by theparticular applications or uses of the present invention. It is intendedthat the claims be construed to include alternative embodiments to theextent that is permitted by prior art and within the spirit of theinvention.

1-30. (canceled)
 31. A method of managing a purchasing contract betweenat least one supplier entity and at least one customer entity, saidmethod comprising the steps of: generating a purchasing contract betweenat least one supplier entity and at least one customer entity, thepurchasing contract being applicable to one or more contractedpurchasing transactions effected, at least partially, through acomputerized system, said generating step including identifying one ormore contract attributes associated with the contract, including one ormore contract terms, each contract term having associated therewith ameasurable performance parameter wherein the value of the performanceparameter is dependent, at least in part, on the occurrence of one ormore contracted transactions, and storing the contract attributesincluding the contract terms in one or more databases; collectingtransaction data relating to one or more purchasing transactions, thecollected transaction data including data representing one or moretransaction attributes associated with each purchasing transaction;executing a computer program to identify one or more of the purchasingtransactions as a contract transaction by selecting one or more of thetransaction attributes and comparing the selected attributes with thecontract attributes, whereby a contract transaction is identified when apredetermined one or more of the selected attributes are identifiablewith one or more of the contract attributes; and executing a computerprogram to measure the performance of a contract term using, as inputdata, transaction attributes of one or more contract transactions. 32.The method of claim 31, further comprising, after the step of collectingtransaction data, the steps of: storing the collected transaction datafor each transaction as a transaction data set; and storing thetransaction data sets in a transaction database in accordance with acommon format; and wherein the step of executing a computer program toidentify contracted transactions, includes accessing the transactiondatabase.
 33. The method of claim 31, further comprising the step ofproviding a term performance rule for determining the fulfillment ofeach contract term, and storing the term rule in one or more computerdatabases, and wherein the step of executing a program to measurecontract term performance includes generating a current term performancevalue and comparing the performance value with a term performance rule.34. The method of claim 31, wherein the step of storing collectedtransaction data includes selecting data representing one or moretransaction attributes selected from the group of transaction attributesconsisting of: product code, product cost, transaction time, transactiondate, seller identifier, computed share, and combinations thereof. 35.The method of claim 31, further comprising the steps of: providing anancillary database containing data representing product attributes ofeach of a supplier's products, whereby an individualized transaction foreach product is identifiable by one or more product attributes;receiving, at a client station, parent transaction data relating to aparent purchase transaction, wherein the parent transaction embodies oneor more individualized transactions; executing a computer program tocompare at least a portion of each parent transaction data with productattributes stored in the ancillary database so as to identify one ormore products; defining an individualized transaction with each of theidentified products, each of the individualized transactions beingassociated with one or more of the transaction data set; and storingeach transaction data set for each individualized transaction in one ormore computer databases.
 36. The method of claim 31, wherein the step ofidentifying one or more contract attributes includes selecting, for thestoring step, one or more contract term attributes from the group ofterm attributes consisting of: term discount, term discount method, termdate range, term performance rules, term identifier, authorizeddistributors, distributor commission, and combinations thereof.
 37. Themethod of claim 31, further comprising the steps of: defining a contractterm identifier for each contract term; and for each identifiedcontracted transaction, associating the transaction data set with thecontract term identifier with which the contract transaction isidentified, whereby the associated transaction data set and the contractterm identifier constitute a contract transaction data set.
 38. Themethod of claim 37, wherein the step of executing a computer program tomeasure contract !term performance includes using, as input, data fromaccessing each of the contracted transaction data sets associated withthe contract term.
 39. The method of claim 38, wherein the step ofmeasuring the performance of the contract term includes selecting, forthe measuring step, a performance value from the group of performancevalues consisting of: total product count, total cost, supplier share,unit cost, and combinations thereof; and wherein the step of storingcontract attributes includes storing a set of contract term attributesfor each contract term, and wherein each of the at least one supplierentity and the at least one customer entity have, associated therewith,one or more entity attributes, said method further comprising the stepsof: specifying one or more entity data representing each of the entityattributes or a combination thereof; and including the entity data ineach term attributes set such that the contract transaction data setincludes entity data. 40-52. (canceled)
 53. The system of claim 52,wherein the data processing system is configured to store eachtransaction data set in a common format.
 54. The system of claim 52,further comprising one or more data processing systems intercoupled withone or more of said data storage systems so as to be accessible with thecontracted transaction data set, wherein said contracted transactiondata sets are stored in said one or more data storage systems.